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(57) ABSTRACT 

A synchronization system providing multi-client synchroni- 
zation is described. By storing the data that is actually being 
synchronized (i.e., storing the actual physical body of a 
memo, for instance) inside an extra database, "Grand Uni- 
fication Database" (GUD), (or by specially-designated client 
data set) under control of a central or core synchronization 
engine, rather than transferring such data on a point-to-point 
basis, the system of the present invention provides a reposi- 
tory of information that is available at all times and does not 
require that any other synchronization client (e.g., PIM 
client or hand-held device) be connected. The GUD provides 
a super-set of the other client data sets. Therefore, if the user 
now includes an additional client, such as a server computer 
storing user information, the synchronization system has all 
the information necessary for synchronizing the new client, 
regardless of whether any of the other clients are currently 
available. The system can, therefore, correctly propagate 
information to any appropriate client without having to "go 
back** to (i.e., connect to) the original client from which that 
data originated. 

39 Claims, 7 Drawing Sheets 
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DATA PROCESSING ENVIRONMENT WITH 

METHODS PROVIDING 
CONTEMPORANEOUS SYNCHRONIZATION 
OF TWO OR MORE CLIENTS 

RELATED APPLICATIONS 

The present application is related to and claims the benefit 
of priority from the following commonly-owned, 
co-pending U.S. provisional patent applications: Ser. No. 
60/069,731, filed Dec. 16, 1997, and entitled Data Process- 
ing Environment with Synchronization Methods Employing 
a Unification Database; Ser. No. 60/094,972, filed Jul. 31, 
1998, and entitled System and Methods for Synchronizing 
two or more Datasets; and Ser. No. 60/094,824, filed Jul. 31, 
1998, and entitled Data Process Environment with Methods 
Providing Contemporaneous Synchronization of two or 
more Clients. The disclosures of the foregoing are hereby 
incorporated by reference in their entirety, including any 
appendices or attachments thereof, for all purposes. The 
present application is also related to the following 
concurrently-filed, commonly-owned U.S. patent 
application, the disclosures of which are hereby incorpo- 
rated by reference in their entirety, including any appendices 
or attachments thereof, for all purposes: Ser. No. 09/136,215 
filed Aug. 18, 1998, and entitled System and Methods for 
Synchronizing two or more Datasets. The present applica- 
tion is also related to the following commonly-owned, 
co-pending U.S. patent applications, the disclosures of 
which are hereby incorporated by reference in their entirety, 
including any appendices or attachments thereof, for all 
purposes: Ser. No. 08/609,983, filed Feb. 29, 1996, and 
entitled System and Methods for Scheduling and Tracking 
Events Across Multiple Time Zones; Ser. No. 09/020,047, 
filed Feb. 6, 1998, and entitled Methods for Mapping Data 
Fields from one Data set to Another in a Data Processing 
Environment, and Ser. No. 08/923,612, filed Sep. 4, 1997, 
and entitled System and Methods for Synchronizing Infor- 
mation among Disparate Datasets. 

COMPUTER PROGRAM LISTING APPENDIX 

The file of this patent contains a computer program listing 
appendix submitted on one compact disc, including a dupli- 
cate compact disc, in a file named "APPENDIX.TXT", 
having a date of creation of May 7, 2001 and a size of 28,286 
bytes. The contents of the compact disc are hereby incor- 
porated by reference. 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

BACKGROUND OF THE INVENTION 

The present invention relates generally to management of 
information or sets of data (i.e., "data sets") stored on 
electronic devices and, more particularly, to a system imple- 
menting methods for maintaining synchronization of dispar- 
ate data sets among a variety of such devices, particularly 
synchronizing three or more devices at a time. 

With each passing day, there is ever increasing interest in 
providing synchronization solutions for connected informa- 
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tion appliances. Here, the general environment includes 
"appliances" in the form of electronic devices such as 
cellular phones, pagers, hand-held devices (e.g., PalmPi- 
lot™ and Windows™ CE devices), as well as desktop 
5 computers and the emerging "NC* device (i.e., a "network 
computer" running, for example, a Java virtual machine or 
a browser). 

As the use of information appliances is ever growing, 
often users will have their data in more than one device, or 

10 in more than one desktop application. Consider, for instance, 
a user who has his or her appointments on a desktop PC 
(personal computer) but also has a battery-powered, hand- 
held device for use in the field. What the user really wants 
is for the information of each device to remain synchronized 

15 with all other devices in a convenient, transparent manner. 
Still further, the desktop PC is typically connected to a 
server computer, which stores information for the user. The 
user would of course like the information on the server 
computer to participate in the synchronization, so that the 

2 q server also remains synchronized. 

A particular problem exists as to how one integrates 
disparate information — such as calendaring, scheduling, and 
contact information — among multiple devices, especially 
three or more devices. For example, a user might have a 

25 PalmPilot ("Pilot") device, a REX™ device, and a desktop 
application (e.g., Starfish Sidekick running on a desktop 
computer). Currently, in order to have all three 
synchronized, the user must follow a multi-step process. For 
instance, the user might first synchronize data from the 

30 REX™ device to the desktop application, followed by 
synchronizing data from the desktop application to the Pilot 
device. The user is not yet done, however. The user must 
synchronize the Pilot back to the REX™ device, to complete 
the loop. Description of the design and operation of the 

35 REX™ device itself (available as Model REX-3, from 
Franklin Electronic Publishers of Burlington, NJ.) is pro- 
vided in commonly-owned U.S. patent application Ser. No. 
08/905,463, filed Aug. 4, 1997, and entitled, User Interface 
Methodology for Microprocessor Device Having Limited 

40 User Input, the disclosure of which is hereby incorporated 
by reference. 

Expectantly, the above point-to-point approach is disad- 
vantageous. First, the approach requires user participation in 
multiple steps. This is not only time consuming but also 

45 error prone. Further, the user is required to purchase at least 
two products. Existing solutions today are tailored around a 
device-to-desktop PIM (Personal Information Manager) 
synchronization, with no product capable of supporting 
concurrent synchronization of three or more devices. Thus 

50 for a user having three or more devices, he or she must 
purchase two or more separate synchronization products. In 
essence, existing products to date only provide peer-to-peer 
synchronization between two points, such as between point 
A and point B. There is no product providing synchroniza- 

55 tion from, say, point A to point B to point C, all at the same 
time. Instead, the user is required to perform the synchro- 
nization manually by synchronizing point A to point B, 
followed by synchronizing point B to point C, then followed 
by point C back to point A, for completing the loop. 

60 As a related disadvantage, existing systems adopt what is, 
in essence, an approach having a "hard-coded" link for 
performing synchronization for a given type of data. 
Suppose, for example, that a user desires to update his or her 
synchronization system for now accommodating the syn- 

65 chronization of e-mail data (e.g., Microsoft® Outlook 
e-mail). With existing synchronization products, the user 
cannot simply plug in a new driver or module for supporting 
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this new data type. To the point, existing products today do 
not provide a generic framework into which data type- 
specific modules may plug into. As a result, these products 
are inflexible. In the event that the user encounters a new 
type of data for which synchronization is desired, he or she 5 
is required to update all or substantially all of the synchro- 
nization product. The user cannot simply plug in a driver or 
module for supporting synchronization of the new data type. 
All told, existing synchronization products today assume 
that users will only perform point-to-point (i.e., two device) to 
synchronization, such as between a hand-held device and a 
desktop application running on a PC. 

This assumption is far removed from reality, however. 
Users are more likely today to have data among multiple 
devices, such as among a desktop computer, a server com- 15 
puter (e.g., company network at the user's place of 
employment), and two or more portable devices (e.g., a 
laptop computer and a hand-held device). Given the sub- 
stantial effort required to manually keep three or more 
devices synchronized, the benefits of synchronization 20 
largely remain unrealized for most computer and informa- 
tion application users today. 

What is needed is a system providing methods which 
allows a user of information processing devices to synchro- 
nize user information, such as user-supplied contact lists, 25 
from one device to any number of other devices, including 
three or more devices concurrently. The present invention 
fulfills this and other needs. 

SUMMARY OF THE INVENTION 30 

The present invention introduces the notion of a reference 
database: the Grand Unification Database or GUD. By 
storing the data that is actually being synchronized (i.e., 
storing the actual physical body of a memo, for instance) 35 
inside an extra database (or by specially-designated one of 
the client data sets) under control of a central or core 
synchronization engine, rather than transferring such data on 
a point-to-point basis, the system of the present invention 
provides a repository of information that is available at all 40 
times and does not require that any other synchronization 
client (e.g., PIM client or hand-held device) be connected. 
Suppose, for instance, that a user has two synchronization 
clients: a first data set residing on a desktop computer and a 
second data set residing on a hand-held device. The GUD 45 
introduces a third data set, a middleware database. This third 
data set provides a super-set of the other two client data sets. 
Therefore, if the user now includes a third client, such as a 
server computer storing user information, the synchroniza- 
tion system of the present invention has all the information 50 
necessary for synchronizing the new client, regardless of 
whether any of the other clients are currently available. The 
system can, therefore, correctly propagate information to 
any appropriate client without having to "go back" to (i.e., 
connect to) the original client from which that data origi- 55 
nated. 

Internally, the system of the present invention employs 
"type plug- in" modules, each one for supporting a particular 
data type. Since the core synchronization engine treats data 
generically as "blob" objects, type-specific support is pro- 60 
vided by the corresponding plug-in module. Each plug-in 
module is a type-specific module having an embedded 
record API (application programming interface) that each 
synchronization client may link to, for providing type- 
specific interpretation of blob data. For instance, the system 65 
may include one type-specific record API for contact 
information, another for calendar information, and yet 
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another for memo information. In this manner, each client 
may employ a type-specific API for correctly interpreting 
and processing particular blob data. The engine, on the other 
hand, is concerned with correct propagation of data, not 
interpretation of that data. It therefore treats the data itself 
generically. In this fashion, the present invention provides a 
generic framework supporting concurrent synchronization 
of an arbitrary number of synchronization clients or devices. 

Also internally, the synchronization system of the present 
invention employs an "action queue," for optimizing the 
actual synchronization work performed. In contrast to con- 
ventional point-to-point (i.e., binary) synchronization 
systems, the synchronization system of the present invention 
does not immediately transmit updates or changes as soon as 
they are detected. Instead, the system determines or tabu- 
lates changes, net of all clients, before undertaking the actual 
work (e.g., record insertion) of synchronizing a particular 
client. In particular, all actions or tasks which are to be 
performed for a client by the system during synchronization 
are queued io the outbound action queue. This allows the 
system to apply synchronization logic or intelligence to the 
queue for further improving system performance, such as 
eliminating any activities which are redundant or moot. For 
example, if the system receives a request from two different 
clients to update a given record (i.e., conflict), the system, 
applying internal synchronization logic, can eliminate 
propagating the first update, as it is rendered moot by the 
second update. In this manner, the system can apply a 
first-level resolution of requests that are conflicting (or 
complimentary) and, as a result, eliminate those synchroni- 
zation activities which are redundant or moot 

An exemplary method for synchronizing multiple data 
sets includes first establishing a data repository for facili- 
tating synchronization of user information maintained 
among multiple data sets, the data repository storing user 
information from the data sets. At least one mapping is 
stored which specifies how user information may be trans- 
formed for storage at a given data set. Upon receiving a 
request for synchronizing at least one data set, the system 
may, based on user information stored at the data set(s) and 
based on the mapping, propagate to the data repository from 
each data set(s) any changes made to the user information, 
to the extent that such changes can be reconciled with user 
information already present at the data repository. Further, 
based on user information stored at said data repository and 
based on the mapping, the system may propagate to each 
data set(s) any changes to the user information which have 
been propagated to the data repository, to the extent that 
such changes are not present at the data set. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 A is a block diagram of a computer system in which 
the present invention may be embodied. 

FIG. IB is a block diagram of a software system of the 
present invention for controlling operation of the system of 
FIG. 1A. 

FIG. 2 is a block diagram of the synchronization system 
of the present invention. 

FIG. 3 is a block diagram of a GUD of the present 
invention. 

FIGS. 4A-C are flow charts of the operation of the 
synchronization system of the present invention. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

The following description will focus on the presently- 
preferred embodiment of the present invention, which is 
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operative in an environment typically including desktop 
computers, server computers, and portable computing 
devices, occasionally or permanently connected to one 
another, where synchronization support is desired. The 
present invention, however, is not limited to any particular 5 
environment or device. Instead, those skilled in the art will 
find that the present invention may be advantageously 
applied to any environment or application where contem- 
poraneous synchronization among an arbitrary number of 
devices (i.e., "synchronization clients"), especially three or 10 
more devices, is desirable. The description of the exemplary 
embodiments which follows is, therefore, for the purpose of 
illustration and not limitation. 
System Hardware and Software 

The present invention may be embodied on an informa- 15 
tion processing system such as the system 100 of FIG. 1A, 
which comprises a central processor 101, a main memory 
102, an input/output (I/O) controller 103, a keyboard 104, a 
pointing device 105 (e.g., mouse, pen device, or the like), a 
screen or display device 106, a mass storage 107 (e.g., hard 20 
disk, removable floppy disk, optical disk, magneto-optical 
disk, flash memory, or the like), one or more optional output 
device(s) 108, and an interface 109. Although not shown 
separately, a real-time system clock is included with the 
system 100, in a conventional manner. The various compo- 25 
nents of the system 100 communicate through a system bus 
110 or similar architecture. In addition, the system 100 may 
communicate with other devices through the interface or 
communication port 109, which may be an RS-232 serial 
port or the like. Devices which will be commonly connected 30 
to the interface 109 include a network 151 (e.g., LANs or the 
Internet), a laptop 152, a handheld organizer 154 (e.g., the 
REX™ organizer, available from Franklin Electronic Pub- 
lishers of Burlington, NJ.), a modem 153, and the like. 

In operation, program logic (implementing the method- 35 
ology described below) is loaded from the storage device or 
mass storage 107 into the main memory 102, for execution 
by the processor 101. During operation of the program 
(logic), the user enters commands through the keyboard 104 
and/or pointing device 105 which is typically a mouse, a 40 
track ball, or the like. The computer system displays text 
and/or graphic images and other data on the display device 
106, such as a cathode-ray tube or an LCD display. A hard 
copy of the displayed information, or other information 
within the system 100, may be obtained from the output 45 
device 108 (e.g., a printer). In a preferred embodiment, the 
computer system 100 includes an IBM PC-compatible per- 
sonal computer (available from a variety of vendors, includ- 
ing IBM of Armonk, N. Y.) running Windows 9x or Windows 
NT (available from Microsoft Corporation of Redmond, so 
Wash.). In a specific embodiment, the system 100 is an 
Internet or intranet or other type of network server and 
receives input from and sends output to a remote user via the 
interface 109 according to standard techniques and proto- 
cols. 55 

Illustrated in FIG. IB, a computer software system 120 is 
provided for directing the operation of the computer system 
100. Software system 120, which is stored in system 
memory 102 and on storage (e.g., disk memory) 107, 
includes a kernel or operating system (OS) 140 and a 60 
windows shell 150. One or more application programs, such 
as client application software or "programs" 145 may be 
"loaded" (i.e., transferred from storage 107 into memory 
102) for execution by the system 100. 

System 120 includes a user interface (UI) 160, preferably 65 
a Graphical User Interface (GUI), for receiving user com- 
mands and data and for producing output to the user. These 
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inputs, in turn, may be acted upon by the system 100 in 
accordance with instructions from operating system module 
140, windows module 150, and/or client application module 
(s) 145. The UI 160 also serves to display the user prompts 
and results of operation from the OS 140, windows 150, and 
applications) 145, whereupon the user may supply addi- 
tional inputs or terminate the session. In the preferred 
embodiment, OS 140 and windows 150 together comprise 
Microsoft Windows software (e.g., Windows 9x or Windows 
NT). Although shown conceptually as a separate module, the 
UI is typically provided by interaction of the application 
modules with the windows shell and the OS 140. 

Of particular interest herein is a synchronization system 
or "Synchronizer" 200 of the present invention, which 
implements methodology for contemporaneous synchroni- 
zation of an arbitrary number of devices or "clients." Before 
describing the detailed construction and operation of the 
Synchronizer 200, it is helpful to first briefly review the 
basic application of synchronization to everyday computing 
tasks. 

Brief Overview of Synchronization 

A. Introduction 

Many software applications, such as personal productivity 
applications as Starfish Sidekick® and Lotus® Organizer, 
have sets of data or "data sets" (e.g., address books and 
calendars). Consider for instance a user scenario where an 
account executive needs to coordinate contacts and events 
with other employees of the XYZ corporation. When 
traveling, this executive carries a laptop PC with Starfish 
Sidekick® installed. At home, she and her husband use 
Lotus® Organizer to plan their family's activities. When on 
family outings, the account executive carries her Palm Pi- 
lot™ hand-held organizer. As the foregoing illustrates, a user 
often needs a means for synchronizing selected information 
from the data sets his or her applications rely upon. The 
account executive would not want to schedule a business 
meeting at the same time as a family event, for example. 

Conventionally, the process of synchronizing or reconcil- 
ing data sets has been a binary process — that is, two logical 
data sets are synchronized at a time. Any arbitrary synchro- 
nization topology will be supported. Here, the system guar- 
antees synchronization stability and the avoidance of unde- 
sirable side effects (cascading updates, record duplication, or 
the like). Data sets do not need to be directly connected but, 
instead, can be connected via a "store-and-forward" 
transport, such as electronic mail. 

B. Synchronization Design 
1. Synchronization Type 

Data set synchronization may, for convenience of 
description, be divided into two types: content-oriented and 
record-oriented. Content-oriented synchronization corre- 
lates data set records based on the values of user-modifiable 
fields. Value correlation requires semantic (or at least 
advanced syntactic) processing that the human brain is very 
good at and computers are not. For example, a record in one 
data set with a name field valued "Johann S. Bach" and a 
record in a second data set with a name field valued "J. S. 
Bach" could possibly refer to the same real-world person. A 
human being might arrive at this conclusion by correlating 
associated data (addresses) or drawing upon external infor- 
mation (e.g., Bach is an unusual name in the U.S.). Creating 
program logic or code with the ability to make these type of 
decisions is computationally very expensive. 

Record-oriented synchronization correlates data set 
records by assuming that each record can be uniquely 
identified throughout its lifetime. This unique identifier is 
usually implemented as a non-modifiable, hidden field con- 
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taining a "Record ID". Record-oriented synchronization It is often the case that there are significant differences in the 
algorithms usually require maintaining a mapping from one number, size, type and usage of fields between two data sets 
set of record IDs to another. In a preferred embodiment, the in a synchronization relationship. The specification of trans- 
system employs record-oriented synchronization. formations is typically user-configurable, with the underly- 

Record-oriented synchronization is conceptually simple 5 mg system providing defaults. 
andmayh«summarizedasfollows.Inmerulesbetow,Aand with ^ underslandin g of the basic process o£ synchro . 

liOft'J? ^ ? Wh ' Cb JTL* s y nch ' omj ? tIOD nizing information or computing devices, the reader may 

relationship. The rules are assumed to be symmetncal now tetter appreciate me teachings of the present invention 

1. A and IB must teack sumlar types of data (e.g if A is for p roviding methodology for contemporaneous 
an address book^ then B must be an address book). 10 synchroni2at 1 on P of ^ ^ n f mber of dev P ices f 

2. A record entered in A, will create a record m B. synchronization clients). The following description focuses 
reclrd^ R m K ^ corres P ondm 8 on specific modifications to a synchronization system for 

. „ r m . ' . . ..„ , . , , implementing the improved synchronization methodology. 
4. If record Al has been modified I m A and the corre- Synchronization System Providing Contemporaneous Syo- 
sponding record Bl has been modified in B, the record 15 chronizatioil of ^ or morc clic ^. 
with me ktest tm^stamp takes precedence. A. General Design Considerations 
The rules presented above reduce the occurrence of unde- j .i_ ? . 
sirable side effects with a network of synchronized data sets. . . ™ C f"^ ™^? n ^*»™ ^ D0tl0n of a Gra ° d 
2 Timestamps Unification Database" (GUD>— a central repository or ref- 
ine actual s^chronization logic in synchronization sys- ^ database fo ' ^ d /! a * B * storin S 1116 data » 
terns often needs to make processing decisions based on 20 **** ro . Dlzed skmn S me actual physical 
comparing the time at which past events occurred. For ^ody of a memo, for instance) inside an extra database (or 
example, it is necessary to know if a record was modified b ? specially-designated one of the client data sets) under 
before or after the last synchronization transaction. This control of a central or core synchronization engine, rather 
requires recording the time of various events. A "timestamp" man transferring such data on a point-to-point basis, the 
value may be employed to this purpose. Typically, data sets 25 system of the present invention provides a repository of 
involved in synchronization support timestamps, or can be information that is available at all times and does not require 
supplied with suitable timestamps, in a conventional man- that ^y other synchronization client (e.g., PIM client or 
ner. In conjunction with the usage of timestamps to compare hand-held device) be connected. Suppose, for instance, that 
the relative timing of record creation or modification, the a user has two synchronization clients: a first data set 
clocks on the respective devices may themselves be syn- 30 residing on a desktop computer and a second data set 
chronized. residing on a hand-held device. The GUD introduces a third 

3. Record Transformations data ^ a middleware database. This third data set provides 
During synchronization, a synchronization system will a super-set of the other two client data sets. Therefore, if the 

typically transform records from one application-usage- user now includes a third client, such as a server computer 

schema set to another application-usage-scbema set, such as 35 storin g user information (or other information which the 

transforming from a Starfish Sidekick® card file for busi- }1SCI desires synchronization to), the synchronization system 

ness contacts to a corresponding PalmPilot™ data set. oftne present invention has all the information necessary for 

Typically, there is a one-to-one relationship between records synchronizing the new client, regardless of whether any of 

in these two data sets, that is, between the source and target me omer clients are currently available. The system can, 

data sets. If this is not the case, however, the component of 40 therefore, correctly propagate information to any appropri- 

the system that interacts with a non-conforming data set may ate cuent without having to "go back" to (i.e., connect to) the 

include logic to handle this non-conformance. original client from which that data originated. 

The record transformations themselves are a combination Internally, the system of the present invention employs a 

of field mappings and conversions from a source record to driver-based architecture providing type-specific "plug-in" 

a target record. Exemplary types of field mappings include, 45 m °dules, each one for supporting a particular data type, 

for instance, the following. Since the core synchronization engine treats data generically 

1. Null Source field has no equivalent field in the target as " blob " type-specific support is provided by the 
data set and is ignored during synchronization. corresponding plug-in module. Each plug-in module is a 

2. One-to-One Map exactly one field in the target to one ^yP^P^ific module having an embedded record API 
field in the source 50 ( a PP llcatl0n programming interface) that each synchronize- 

3. One-to-Many Map one field in the target to many fields 5? "^^J to '. fo ' P rovi ^ m 8 ^re- 
in the source, such as parse a single address line to ° f ** * IZlT"*', , ^ 7* T 
fi . . r *. j. 5 , . 6 . 4 , _ t type-specific record API for contact information, another for 
nelds for number, direction, street, suite/apartment, or ' , , T . f , t . - * . - 

the like calendar information, and yet another for memo lnforma- 

a w / ^ w .a * * . » 55 tion. In this manner, each client may employ a type-specific 

f^- t P ^T 1 6 ^ m ih u ^ 10 ?™ ^ for «™^y interpreting and processing particular blob 

field id the source, such as reverse the address hoe data ^ cngin ^ on thc othef ^ fa with 

mapping above. correct propagation of data, not interpretation of that data. It 

Similarly, exemplary field conversions may be defined as merefore treats the data itself genericaUy. In this fashion, the 

°i°c^ o c u u i it • • 60 present invention provides a generic framework supporting 

1. Size Source field may be larger or smaller m size than concurrent synchronization of an arbitrary number of syn- 
the target field. chronization clients or devices. 

2. Type Data types may be different, such as float/integer, Also internally, the synchronization system of the present 
character vs. numeric dates, or the like. invention employs an "action queue," for optimizing the 

3. Discrete Values A field's values may be limited to a 65 actual synchronization work performed. In contrast to con- 
known set. These sets may be different from target to ventional point-to-point (i.e., binary) synchronization 
source and may be user defined. systems, the synchronization system of the present invention 
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does not immediately transmit updates or changes as soon as 
they are detected. Instead, the system determines or tabu- 
lates changes, net of all clients, before undertaking the actual 
work (e.g., record insertion) of synchroni2ing a particular 
client. In particular, all actions or tasks which are to be 5 
performed for a client by the system during synchronization 
are queued in the outbound action queue. This allows the 
system to apply synchronization logic or intelligence to the 
queue for further improving system performance, such as 
eliminating any activities which are redundant or moot. For 10 
example, if the system receives a request from two different 
clients to update a given record (i.e., conflict), the system, 
applying internal synchronization logic, can eliminate 
propagating the first update, as it is rendered moot by the 
second update. In this manner, the system can apply a 15 
first-level resolution of requests that are conflicting or 
complementary and, as a result, eliminate those synchroni- 
zation activities which are redundant or moot 

B. Overview of Synchronization System Internal Archi- 
tecture 20 

FIG. 2 is a block diagram illustrating a modular or 
high-level view of the synchronization system 200. As 
shown, the synchronization system 200 includes a synchro- 
nization engine (core) 230 that is connected to both a Grand 
Unification Database(s) (GUD(s)) 210 and to an action 25 
queue 240. As also shown, the engine presents two 
interfaces, a client API 220 and type API 250, for commu- 
nicating with components outside the core engine. 

The GUD 210, as previously described, serves as a central 
repository storing record data and mappings which dictate 30 
how records are transformed (i.e., from one data set to 
another). The synchronization engine 230 includes generic 
logic for managing the GUD 210, including locating and 
interpreting information in the GUD. Based on the infor- 
mation in the GUD 210 and client requests, the synchroni- 35 
zation engine 230 builds the action queue 240, adding or 
removing specific tasks from the queue as necessary for 
carrying out synchronization transactions. The action queue 
240 itself is an array of task entries; it may grow or shrink, 
depending on the current number of entries that it stores. In 40 
the currently-preferred embodiment, the array is sorted by 
record ID, that is, according to the record ID of the corre- 
sponding record from the GUD. Since entries are sorted by 
record ID, the task of identifying entries in conflict is 
simplified. 45 

To communicate with the clients, the synchronization 
engine 230 employs the client API 220. The client API 
provides database engine-like functionality. For example, 
API function calls are provided for moving to records, 
reading records, and writing records. In the currently- 50 
preferred embodiment, clients accessors 221, 223 are 
"accessor** portions of the synchronization system which, in 
turn, communicate directly with the "real" clients, such as 
REX. By implementing its architecture such that all clients 
communicate commonly through the client API 220, the 55 
system 200 provides plug-in capability for supporting new 
clients. 

In order for the system to correctly determine record 
information in the GUD 210, the synchronization engine 
230 communicates with type drivers or modules (e.g., X 60 
type 251 and Y type 253) through the type API 250. As 
previously described, each type, such as calendar, contacts, 
and the like, is associated with a particular type module. The 
type API 250 allows the synchronization engine 230 to ask 
common questions about information stored in the GUD 65 
210. For example, if the synchronization engine 230 needs 
to determine whether two records are identical, it can request 
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a record comparison operation by the corresponding type 
module, using the type API 250. In comparison to the client 
API 220, the type API 250 is comparatively small. By 
implementing its architecture such that all type-specific 
requests are communicated commonly through the type API 
250, the system 200 provides built-in extensibility. When 
support is desired for a new type, one need only plug in a 
new type module. Any client which wants to communicate 
with that new type now has automatically gained support for 
that new type. In the currently-preferred embodiment, a type 
module is unaware of any specific clients which it supports. 
Clients, on the other hand, typically know what types that 
each desires to synchronize with. 

As also shown, each client accessor can communicate 
directly with the type modules, using a record API 260. In 
the currently-preferred embodiment, each type module sur- 
faces its own record API, such as record API 260 for type 
module 251. The underlying record API is specific for each 
type. Each accessor communicates with a desired type 
module, not through the synchronization engine 230, but 
instead through the exposed record API for the desired type. 
Thus, in effect, there is a direct communication path between 
client accessors and type modules. In typical use, the record 
API is employed by a client accessor to create or write 
record-specific information. For example, if the client 
desires to write a "subject" for a contact record, the client, 
operating through the corresponding client accessor, can 
invoke the corresponding record API for requesting this 
service. In response to invocation of the record API, the 
corresponding type module would service the API call for 
assisting with creating or editing the underlying record, in 
the matter requested by the client. The actual work of 
creating or editing the record is typically performed by the 
client; however, the corresponding type module returns 
specific information about the given type, so that the client 
knows exactly how the record is structured. As a simple 
example, the record API might return information indicating 
that a particular record type consists of a structure having 
four string data members, each being 64 bytes long. Based 
on such information, the client now knows how to interpret 
and process that type. 

C. Synchronization System Detailed Internal Architecture 

1. GUD 

FIG. 3 is a block diagram illustrating organization of a 
GUD 300. In the currently-preferred embodiment, the sys- 
tem implements one GUD per type. For instance, if one were 
synchronizing contacts, calendars, and "to do"s (i.e., task- 
oriented information), one would have three GUDs, one for 
each type. As shown, each GUD database internally stores 
two sets of tables: mapping tables 320 and data table 310. 
The data table 310 stores the actual record data 313 (i.e., 
blob data), together with a unique reference (ref) ID or 
"GUD ID" 311. In the presently-preferred embodiment, each 
reference ID (e.g., a 32-bit or 64-bit ID) is unique not only 
within its particular GUD database but also across all GUD 
databases. Thus, for example, the system would not dupli- 
cate a calendar reference ID in the contact GUD database. 
With this approach, the individual data items are uniquely 
identified across the entire system. If desired, the GUD itself 
(or its data record portion) may be implemented as one of the 
actual client data sets (i.e., one of the data sets serves as the 
GUD, or portion thereof). 

Also shown, mapping tables 320 store entries comprising 
a reference ID 321, a source ID 322, a checksum or integrity 
value (e.g., CRQ 323, and a last modification (mod) times- 
tamp 324. The reference ID 321 is the same ID as associated 
with a record in the data table 310. The source ID 322 is the 
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record ID for the record, as it was received from the client. connected. In a manner similar to that described above for 

TTie last modification timestamp 324 establishes when the the GUD, the system can specify an update 

record was last synchronized through the system. The times- (CUENT 13 UPDATE), add (CLIENT 13 ADD), and/or delete 

tamp (e.g., system time structure) reflects the time on the (CLI ENT 13 DELETE) action, on a per client basis. In the 

system clock of the machine which is being synchronized. 5 instance of an update or delete action, there already exists a 

Optionally, the system stores a comparison value or check- corresponding mapping table item. For an add action, 

sum (e g., cyclic redundancy checking or CRQ 323, for use however> the systern undertakes as its first action item the 

with those clients that do not support timestamps If the ^ of creating a new mapping table item . Therefore, when 

checksum is not used the system stores 0 as its value. me fldd action fa eveQtuall rforme4 ±t lable item ^ be 

Each table itself is linked to a particular client, through a 10 , A ,, r\ *u X u j i_ u *• i_ 

. li m .l. J L - * *r created as well. On the other hand, should the action be 

table ID, with the correspondence being stored as configu- , , 4 L1 . >«< . 4 , 

• r y-L'^-L i r . ° . canceled, the mapping table item will not be created, 

ration information (which in the currently-preferred envi- ' FP 5 

ronment exists as a higher level than the synchronization Additional pieces of information are tracked by each entry 

engine). In this manner, each one of the mapping tables can m tne action queue: (1) record data, (2) source client, and (3) 

be associated with an appropriate client, TTie end result is 15 timestamp. The record data is the actual data (or a reference 

that the system maintains a mapping table for each client. to tne actual data) obtained from the client. In this manner, 

Thus, for a given record ID, the system can easily determine me actual data may be associated with a particular action, 

(from the above-described reference ID-to-source ID The source chent indicates which client the action originated 

correspondence) where that record maps to for all clients. from - is useful, for instance, during synchronization, so 

Consider, for instance, a particular record residing on a REX 20 mat tne system does not attempt to synchronize the client 

device. Based on the source ID for that record, the system from which the data just arrived. The timestamp stored in an 

can determine from the mapping table the corresponding action queue entry is the last modification time of the record 

mapping table item for that source ID. Now, the system has ^om the source client. This is stored for possible use during 

sufficient information allowing the particular record to be conflict resolution (which is described in further detail 

synchronized, as required by the user. When the data is 25 below). 

completely synchronized with all clients, all mapping tables As previously described, the entries in the action queue 

in the system will store that record ID (i.e., the record ID is are sorted by reference ID. In this manner, the system can 

now common to all tables once the data is completely quickly determine action queue entries which are potentially 

synchronized with all clients). in conflict. For example, if the queue contains three entries 

2. Action Queue 30 all having the same reference ID, the system must examine 

The action queue stores entries of a particular action type, those entries for uncovering any conflicts. The actual con- 

which are used during synchronization to indicate all actions flict resolution rules applied in the system are described 

needed to be performed by the system. In the currently- below. 

preferred embodiment, six action types are defined: 3 Methodology of System Operation 

(1) GUD 13 UPDATE 35 FIG. 4A illustrates an overall methodology 400 of the 

(2) GUD 13 ADD present invention for providing synchronization contempo- 

(3) GUD 13 DELETE raneously among an arbitrary number of clients. At step 401, 

(4) CLIENT UPDATE mc svstcm initializes all clients and types (data structures). 

(5) CLIENT ADD ^ stc P ^ c svstcm establishes a 1°°P f° r determining 
(G\ Cl TFNT^nFi FTF *° ^ or eac k cuent w ** at act i° QS are to °e performed. Here, the 

_ ' \ . 13 . 4 . „ . system begins building the action queue. Once the action 

He first three acton types or "GUD acnon types indicate of taWe has ^ bui , ^ ^ tQ fesolve 

actions to be performed against the GUD. tor example, if n , 

This is indicated bv step 403. In 

the system receives a new record from a chent, it must add rt / t - nt ■ pto „ ^ IctAm ^f~.™ ~~ 

. * , A . , ,. x ~„~ ...... , particular at this step, the system penorms housekeeping on 

the new record to the (corresponding) GUD; this is indicated 45 • . • , 

L . v . . 6y . ' _._ ™ „ , the queue, removing any action entries which are unneces- 

by an action queue entry having a type of GUD l3 ADD. In 

operation the system will not only add the record to the resollltion ret ^ rcs exnbnitkm. As pre- 

corresponding GUD but, also, wdl eventually add that M desaixd> tne 6ntrics in , he actio £ m ^ 

record to other Cents which are associated with that record b refcrence , D In thjs m ^ £m ickl 

as well (unless the user instructs otherwise). In a similar so < . • , . • • 4 .... / 

^™ nnniTP ^ *T "„ determme action queue entries which are potentially in 

manner, a GUDtoUPDATE action item or command will a - . i- i . • * L * ■ n 

77 , 33 j L V,. ~i T T zr r conflict. For example, if the queue contains three entries all 

result in the system updating the corresponding GUD for a havin ^ ^ reference ID ^ ffl must examine 

given record (e.g as a result of that record having been ^ose entries for uncovering any conflicts. Not only are items 

modified at the chent), and a GUD 13 DELETE action nem or fa the ^ M * / refereDce ID but> / s a second 

command w,U result ui the system deletmg the ^record from ss , evel of Q[d ^ ,„ J e i]sQ ^ „ a ^ don GUD 

the corresponding GUD (e g.. ^ a result of that record afe a , ^ tQ ^ ^ ^ hlis ^ ^ 

£ g %?v^ ? ?■ C )- a -a- • , Pri° rit y over other ,v P es - Now > foUowing exemplary 

The CLIENT action types are used to indicate particular nso Mon rules may be applied: 

synchronization work which is required to be performed for 

a particular client. Suppose, for instance, that the synchro- 60 
nization engine determines that the REX client needs to be 

updated, as a result of actions undertaken by other clients; Rule 0: gud_update + 

the REX client need not be currently available (e.g., need not <;cotry(ies) othci than Oud_update> 

be currently connected to the system). In such a case, the Rul<j y g[Slu™ra *** ^ 

engine can post to the action queue appropriate action 65 " GUD_UPDXre 

entries for indicating the synchronization work which is GUD_UPDATE wiih greatest timestamp wins (oi display Ul) 
required to be performed the next time the REX client is 
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■continued 



Rule 2: 


GUD__UFDAPE + 




GUD_DELETE 




GUD_UPDATE (take data over non-data) 


Rule 3: 


CUENT_UPDATE + 




CUENT_ U PDATE (from another client) 




Leave both (i.e., same) 



Once conflicts have been resolved the action queue is ready 
for use. Specifically, at step 404, the system processes all 
remaining action entries in the action queue. The actions 
themselves are performed on a transaction-level basis, 
where a transaction comprises all actions performed on a 
given record GUD ID. Thereafter, the system may perform 
cleanup, including closing any open databases and freeing 
any initialized data structures (e.g., type). 

FIG. 4B illustrates particular substeps which are per- 
formed in conjunction with step 402. The substeps are as 
follows. At step 421, the system determines all updates and 
adds originating from the client (i.e., the client currently 
being processed during the "for** loop). In essence, the 
system operates by asking the client for all modifications 
(e.g., updated or added records) since last synchronization. 
Once these are learned, the system places them in the action 
queue, either as a GUD 13 UPDATE or GUD 13 ADD. If 
desired, a filter may be applied at this point, for filtering out 
any records which are desired to be omitted from the 
synchronization process. The next step, at step 422, is for the 
system to determine any deletions coming from the client. 
Note, here, that the update/add step (421) comes before the 
deletion determination step (422). This allows the system to 
determine what is new before determining what has been 
deleted. As an optimization at this point, the system can look 
at the record count at the client for determining whether in 
fact there have been any deletions at all. In the event that the 
count indicates no deletions, the system can eliminate the 
time-consuming process of determining deletions (which 
may require the system to examine numerous records 
individually). At step 423, the system makes a reverse 
determination: determining any updates or adds which need 
to be sent from the GUD back to the client. The mapping 
table stores a timestamp indicating when the client was last 
synchronized as well as a timestamp for each record item. 
Accordingly, the system can determine whether the item 
needs to be updated or added at the client. In the currently- 
preferred embodiment, the timestamp is generated based on 
the system clock of the client which is undergoing synchro- 
nization. Finally, at step 424, the system determines any 
deleted records in the GUD, for indicating which corre- 
sponding records should be deleted from the client. Specifi- 
cally in the mapping table, each entry includes a deletion 
flag which may be set for indicating deletion of the corre- 
sponding record. These foregoing steps are performed for all 
clients undergoing synchronization, until the action queue is 
filled with the appropriate action entries required for effect- 
ing synchronization. 

FIG. 4C illustrates particular substeps which are per- 
formed in conjunction with step 404. The substeps are as 
follows. At step 431, the system determines whether the 
action is from one client to another client. If the action is to 
a client, the system may simply proceed to update the client, 
as indicated by step 432. If, on the other band, the action is 
from a client, the system must update the GUD, as indicated 
at step 433, and, in turn, propagate the update to the other 
clients, as indicated at step 434. The actual propagation is 
performed recursively invoking itself as client actions 
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(rather than GUD actions). Here, the system fabricates a 
surrogate or fake action item which is then acted upon as if 
it were from the action queue. All the time during the 
method, the GUD has played an important role as a data 
5 source for those clients which are not currently available. 
Appended herewith as an Appendix A are source code 
listings providing further description of the present inven- 
tion. 

While the invention is described in some detail with 
1Q specific reference to a single-preferred embodiment and 
certain alternatives, there is no intent to limit the invention 
to that particular embodiment or those specific alternatives. 

What is claimed is: 

1. In a data processing environment, a method for syn- 
chronizing multiple data sets, the method comprising: 
15 establishing a data repository for facilitating synchroni- 
zation of user information maintained among multiple 
data sets, said data repository storing user information 
from the data sets; 
^ storing at least one mapping which specifies how user 
information may be transformed for storage at a given 
data set; 

receiving a request for synchronizing at least one data set; 
based on user information stored at said at least one data 
l5 set and based on said at least one mapping, propagating 
to the data repository from each of at said at least one 
data set any changes made to the user information, to 
the extent that such changes can be reconciled with user 
information already present at said data repository; and 
30 based on user information stored at said data repository 
and based on said at least one mapping, propagating to 
each of said at least one data set any changes to the user 
information which have been propagated to the data 
repository, to the extent that such changes are not 
35 present at said each data set; 

wherein a particular one of the data sets resides on a client 
device which is intermittently connected, and wherein 
said steps of propagating are deferred for the particular 
data set until the client device is actually connected. 
40 2. The method of claim 1, wherein said step of propagat- 
ing to the data repository comprises: 
performing selected operations of adding, updating, and 
deleting information at the data repository, so that the 
data repository reflects changes made to user informa- 
45 tion at the data sets. 

3. The method of claim 2, wherein said operation of 
deleting information comprises a logical delete operation of 
marking information as having been deleted. 

4. The method of claim 1, wherein said data repository 
50 stores user information that is a super-set of all user infor- 
mation stored at said multiple data sets. 

5. The method of claim 1, wherein said data repository 
and said at least one mapping comprise a grand unification 
database, for facilitating synchronization among multiple 

55 data sets. 

6. The method of claim 5, wherein one grand unification 
database is created for each type of user information which 
is to be synchronized. 

7. The method of claim 6, wherein said environment 
60 includes types of user information selected from contact, 

calendar, and task-oriented information. 

8. The method of claim 1, wherein each data set comprises 
a plurality of data records, and wherein each data record is 
represented within the data repository. 

65 9. The method of claim 8, wherein each of said data 
records is represented within the data repository by a cor- 
responding data record having a unique identifier. 
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10, The method of claim 1, wherein each mapping com- 
prises a mapping table storing a plurality of mapping entries, 
each mapping entry storing at least a first identifier for 
indicating a particular data record in the data repository 
which the entry is associated with, and a second identifier for 
indicating a particular data record at a particular data set 
which is the source for the user information. 

U. The method of claim 10, wherein each mapping table 
is associated with a particular data set. 

12. The method of claim 10, wherein each mapping entry 
stores particular information useful for determining when its 
associated user information was last modified. 

13. The method of claim 12, wherein said particular 
information comprises a last-modified time stamp, derived 
at least in part from the client device where the associated 
user information was last modified. 

14. The method of claim 12, wherein said particular 
information comprises a checksum value, for use with a data 
set residing at a client device that does not support time 
stamps. 

15. The method of claim 1, wherein said step of propa- 
gating to each of said at least one data set comprises: 

performing selected operations of adding, updating, and 
deleting information at each of said at least one data set, 
so that said each reflects changes made to user infor- 
mation at other data sets. 

16. The method of claim 15, wherein said operation of 
deleting information comprises physically deleting informa- 
tion at said each data set 

17. The method of claim 8, wherein at least one of the said 
data sets functions, at least in part, as said data repository. 

18. The method of claim 1, wherein user information is 
stored at the data repository as unformatted blob data. 

19. The method of claim 18, further comprising: 
providing at least one type module for facilitating inter- 
pretation of user information stored as unformatted 
blob data at the data repository. 

20. A method for providing synchronization among an 
arbitrary number of clients, each client storing information 
in data records, the method comprising: 

creating a reference database for storing a set of data 
records serving as a reference to corresponding data 
records stored at the clients; 
creating a list of actions to perform, said list for storing 
instructions specifying that particular data records 
should be added, updated, or deleted at a particular 
client and storing instructions specifying that particular 
data records should be added, updated, or deleted at the 
reference database; 
for each client, 

determining all data records which have been updated, 
added, or deleted at the client since the client was last 
synchronized; 
based on the data records determined to have been 
updated, added, or deleted at the client, posting to 
said list instructions to add, update, or delete corre- 
sponding data records stored at the reference data- 
base; 
for each client, 
determining all data records which have been updated, 
added, or deleted at the reference database since the 
client was last synchronized; 
based on the data records determined to have been 
updated, added, or deleted at the reference database, 
posting to said list instructions to add, update, or 
delete corresponding data records stored at the client; 
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resolving any conflicts present in said list; and 
synchronizing the clients by performing instructions 
remaining in said list. 

21. The method of claim 20, wherein said step of deter- 
5 mining all data records which have been updated, added, or 

deleted at the client includes first determining all data 
records which have been updated and added, and thereafter 
determining all data records which have been deleted. 

22. The method of claim 21, wherein said step of deter- 
10 mining all data records which had been deleted includes: 

first determining, based on record count, whether any 
records at all have been deleted. 

23. The method of claim 20, wherein said resolving step 
includes: 

is . , t . 

prioritizing instructions m the list according to an action 

type; and 

removing from the list any instruction rendered moot as a 
result of a conflicting instruction having a higher type. 
20 24. The method of claim 20, wherein said reference 
database comprises a data set at one of the clients. 

25. The method of claim 20, wherein said the arbitrary 
number of clients comprise three or more clients. 

26. The method of claim 20, wherein said list of actions 
25 includes instructions selected from a client update, a client 

add, and a client delete, for a given data record. 

27. The method of claim 20, wherein said list of actions 
includes instructions selected from a reference database 
update, a reference database add, and a reference database 

30 delete, for a given data record. 

28. The method of claim 20, wherein each data record 
stored at the reference database is uniquely identified, so that 
it may be tracked at each client. 

29. The method of claim 20, wherein an instruction to 
35 update the reference database takes precedence over other 

instructions. 

30. Hie method of claim 20, wherein said instruction to 
delete a corresponding data record at the reference database 
comprises a logical delete operation of marking the record as 

4Q having been deleted. 

31. The method of claim 20, wherein said instruction to 
delete a corresponding data record at a client comprises a 
physical delete operation. 

32. The method of claim 20, wherein said determining 
4 5 steps include using a mapping table for transforming infor- 
mation to and from a particular client. 

33. The method of claim 20, wherein at least one of the 
clients is intermittently connected, so that certain instruc- 
tions in the list are not executed until the client is again 

5 q connected. 

34. The method of claim 20, wherein information from 
data records is stored at the reference database as unformat- 
ted blob data. 

35. A synchronization system providing synchronization 
5S of information among an arbitrary number of client devices, 

each client device storing information in data records, the 
system comprising: 
a reference database for storing a set of data records 
serving as a reference to corresponding data records 
60 stored at the client devices; and 
a synchronization engine for: 
constructing a list of actions to perform, said list for 
storing instructions specifying that particular data 
records should be added, updated, or deleted at a 
65 particular client device and storing instructions 

specifying that particular data records should be 
added, updated, or deleted at the reference database; 
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determining for each client device all data records 
which have been updated, added, or deleted at the 
client since the client was last synchronized, and 
based on that determination, posting to said list 
instructions to add, update, or delete corresponding 5 
data records stored at a reference database; 

determining for each client device all data records 
which have been updated, added, or deleted at the 
reference database since the client was last 
synchronized, and based on that determination, post- 10 
ing to said list instructions to add, update, or delete 
corresponding data records stored at the client; 

resolving any conflicts present in said list; and 

synchronizing the clients by performing instructions 
remaining in said list. 
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36. The system of claim 35, wherein said reference 
database comprises a super-set of data records from the 
client devices. 

37. The system of claim 35, further comprising: 
plug-in type drivers for allowing each client device to 

process information of a particular type. 

38. The system of claim 35, further comprising: 
a client interface allowing a particular client device to 

register with the synchronization engine for obtaining 
synchronization services. 

39. The system of claim 35, further comprising: 
a record interface allowing a particular client device to 

read and write information of a particular record type. 

***** 
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